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REMARKS 

This communication is in response to the Office Action 
mailed March 13, 2007. 

The Office Action first reports that claim 27 depends from 
cancelled claim 26, The dependency of claim 27 has been corrected. 
Withdrawal of the objection is respectfully requested. 

The Office Action next reports that claims 1-9, 11-23, 25 
and 27-34 were rejected has been directed to non-statutory subject 
matter. In particular, some of these claims were rejected for 
reciting "a computer-readable medium''. In response, applicants 
have amended these claims to recite "computer readable storage 
media". Support for this language is found on page 12-13, 

With respect to claims 29-34, the Office Action reports 
that the computer implemented method recited therein does not 
produce a useful, tangible and concrete result in a practical 
application, 

Without conceding that claims 29-34 are non-statutory, 
applicants have amended claim 29 to clarify that client side 
markup is received by the client, which is then executed to create 
a dialog between the user and the client device. In view that 
claim 29 also recites that client side markup is dynamically 
generated on a server remote from the client, it is believed claim 
29 and each dependent claims therefrom sets forth a practical 
application of the invention and provides a useful, concrete, and 
tangible result, namely, a computer implemented method through 
which a user can interact with a client computing device. 

For the foregoing reasons, applicants respectfully request 
withdrawal of the rejection based on 35 U.S.C. 101 is requested. 

The Office Action next reports that claims 1, 15 and 29 
are continued to be rejected under 35 U,S,C. 103(a) as being 
unpatentable over Albayrak et al, in view of White et al. In 
particular Albayrak et al, are cited for disclosing the inventions 
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recited in claims 1, 15 and 29 except for the features ''each of 
the controls having an attribute to indicate whether the 
associated control is available for activation" and u as a function 
of which controls are activated," White et al were cited as 
evidence that these features were well known* Each of the 
specific 

With respect to Albayrak et al*, each of the specific 

citations will be discussed. First, it is again reported that 

cites col, 3, lines 51-55 as disclosing "a set of controls for use 

on a server remote from the client for defining a dialog and used 

to dynamically generate client side markup in accordance with the 

dialog," Col, 3, lines 51-55 state: 

The present invention utilizes standard Internet 
protocols to communicate between client and server 
computers, to dynamically program portable client 
computers, and to manage voice dialogs for the purpose 
of interacting with and guiding users in various work 
tasks , 

Although Albayrak et al, discuss managing voice dialog at 
col* 3, lines 51-55, they do not teach or suggest " a set of 
controls configured for use on a server remote from the client for 
defining a dialog and used to dynamically generate client side 
markup". The cited passage does not state that there is a "set of 
controls". Moreover, where is it stated that the controls are 
specifically enumerated as an answer control and question control 
as recited in each of the independent claims and where the 
controls . 

It is acknowledged that the Office Action also cites Col, 

4, lines 24-28 possibly as support for the concept of a set of 

controls. Col. 4, lines 24-28 state: 

VoiceXML was designed by the VoiceXML Forum to create 
audio dialogs that feature digitized audio and speech 
recognition and to facilitate web-based development and 
content delivery. The voice browser reads a VoiceXML 
page from top to bottom and acts upon the information 
and instructions it reads as it reads them. 
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This passage refers specifically to a "voice browser", 
which is a well-known module that operates on client devices. The 
Office Action has relied principally on the word "instructions"; 
however, it is submitted that this passage is referring to client 
side markup (i.e., the instructions voice browsers on client 
device operate) . This passage simply does not support a set of 
controls operable on the server . 

The Office Action next cites Col. 8, lines 1-67. The 

citations specifically made in the Office Action are to Col. 8 1- 

14, which state: 

VoiceXML pages 250, some of which are pre-coinposed and 
others of which are generated by the SHIM 242 from one 
of a set of VoiceXML templates 252 and parameters 
received from the application 246; 

VoiceXML templates 252, each of which is a document 
written in the VoiceXML language that describes an 
application-specific verbal dialog between the portable 
client and its user; and 

system configuration data 260, including: user 
identification data 262 associated with the users of 
the portable clients; client configuration data 2 64 
concerning the location, the battery state, the 
VoiceXML page currently loaded in the client, and so 
on; 

Again, it is submitted that the cited passages do not 
teach a set of controls operable on the server. At best, maybe the 
VoiceXML templates 252 could be the closest. However, at Col. 9 
lines 12-53, describe the templates 252 in more detail, but these 
templates are not " a set of controls c onfigured for use on a 
server remote from the client for defining a dialog and used to 
dynamically generate client side markup". Moreover, where is it 
stated that the templates have an answer control and question 
control that each have an attribute to indicate whether the 



associated control is available for activation as recited in each 
of the independent claims. 

The feature of the controls having an attribute for 



activation is n ot addr essed In the Office Action, On page 6 of the 



Office Action, citations are made to Col. 4, lines 22-67, Figure 2 

and Col. 6, lines 25-31. Col. 4, lines 22-67 state: 

The particular type of hypertext used in the preferred 
embodiment is based on VoiceXML. VoiceXML was designed 
by the VoiceXML Forum to create audio dialogs that 
feature digitized audio and speech recognition and to 
facilitate web-based development and content delivery* 
The voice browser reads a VoiceXML page from top to 
bottom and acts upon the information and instructions 
it reads as it reads them. 



In a typical application the preferred embodiment works 
in the following manner: 



Upon being powered up, the voice browser on the 
wearable portable client launches a default startup 
program on the server, by requesting a URL associated 
with that startup program. 



The startup program {executed by the server) 
determines, from a database, information about the 
particular client, and sends a voice sign-on VoiceXML 
page to the voice browser thereby programming the 
client to perform the voice sign-on function. 

The voice sign-on page prompts the user to say his or 
her name. If the name is recognized by the speech 
recognition software on the client, the user's voice 
files and application-specific grammar files (both 
needed for speech recognition) are loaded onto the 
client; otherwise this is a new user who must train the 
speech recognition software to understand his voice. 
The following assumes that the user's name is 
recognized. 

When the voice browser reaches the end of the voice 
sign-on page it waits for the next program or page from 
the server, and in this case, a system host interface 
module is launched. 

The system host interface module connects to the third- 
party software and waits to receive the task-specific 
data. Upon receiving the data, the system host 
interface module translates the data into a VoiceXML 
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page and sends it to the voice browser thereby 
programming the client to perform the application . 

The voice browser interprets the page and follows each 
instruction, for example, a} play an audio prompt 
telling the user to go to a particular location, b) 
wait for the user to verbally state his location, c) 
confirm that the user is in the correct location, d) 
play an audio prompt telling the user what to do at the 
current location, e) wait for the user to confirm that 
he completed the requested action, f) play another 
audio prompt if there is one, and continue. 

This description pertains to how the voice browser 
interprets the client side markup, but not how the client side 
markup is dynamically generated at the server using the controls 
specified in the independent claims ha ving attributes for 
activation. 

Col. 6, lines 25-31 state: 

A grammar is a set of statements that specify words and 
sentence syntax . For example, a grammar might specify 
that a user is expected to speak a particular number of 
digits, an affirmative or negative response including 
"yes," "no" and variants such as "yep" and "OK," or one 
of a predefined list of locations, perhaps with 
surrounding words. 

This description merely describes how speech recognition 
works, but it does not teach or suggest using the controls 
specified in the independent claims h aving attrib utes for 
activation. 

The Office Action then continues with citations to other 
portions of Albayrak et al. for other elements of the independent 
claims; however, it is respectfully submitted that since Albayrak 
et al, does not teach the features of the independent claims as 
discussed above (having made the citations clearly of record and 
in context as described by Albayrak et al.), the rejection must be 
withdrawn. 

The foregoing remarks are intended to assist the Office 
in examining the application and in the course of explanation may 
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employ shortened or more specific or variant descriptions of some 
of the claim language. Such descriptions are not intended to 
limit the scope of the claims; the actual claim language should 
be considered in each case. Furthermore, the remarks are not to 
be considered exhaustive of the facets of the invention which are 
rendered patentable, being only examples of certain advantageous 
features and differences, which applicant's attorney chooses to 
mention at this time. For the foregoing reasons, applicant 
reserves the right to submit additional evidence showing the 
distinction between applicant's invention to be unobvious in view 
of the prior art. 

Furthermore, in commenting on the references and in 
■order to facilitate a better understanding of the differences 
that are expressed in the claims, certain details of distinction 
between the same and the present invention have been mentioned, 
even though such differences do not appear in all of the claims. 
It is not intended by mentioning any such unclaimed distinctions 
to create any implied limitations in the claims. 

For the foregoing reasons, Applicant submits that the 
present application is in allowable form. Allowance of the present 
application is respectfully requested. 

Applicant hereby requests an extension of time to respond 
to the Office Action. A charge authorization for the extension of 
time fee is included herewith. 

The Director is authorized to charge any fee deficiency 
required by this paper or credit any overpayment to Deposit 
Account No. 23-1123. 

Respectfully submitted, 

WE3TMAN, CHAMPLXN & KELLY, P. A. 

By: /Steven M. KoehleR/ Reg, No, 36,188 
900 Second Avenue South, Suite 1400 
Minneapolis, Minnesota 55402-3319 
SMK:dkm Phone: (612) 334-«3222 Fax: (612) 334-3312 



